• In addition to ?, +, and *, there are ??, +?, and *?, which capture the least amount possible as they do in regex.
• There are {x} and {x,y} as in regex to repeat a clause x times or between x and y times.
• You can specify a rule name within another rule by using :=, as in (BLAH* phew:=(FOO+ BAR))*?. This would simply give the expression that matches FOO+ BAR the label phew in the parsed tree if it follows an expression matching BLAH*.
• You can specify a starting rule that will encompass the entire parsed text, for example by specifying start foo. By default the rule that encompasses the entire text is the first rule specified in the grammar.
• The specification should probably include backreferences to previously captured groups like regex has, using \1, \2, etc. like in regex. The problem with that, though, is that we’d have to have both capturing grouping and non-capturing grouping like in regex, but the normal, non-capturing grouping used in PEG uses (), while () in regex is capturing and (?:) is non-capturing. I wouldn’t want to use (?:) for non-capturing and () for capturing because non-capturing would by far be the more popular usage and () is simpler to type and to read. And I wouldn’t want to reverse ()‘s and (?:)‘s roles because that would be confusing. So I’d have to figure something out.
• I thought of allowing specification of regex tokens done in the same way as specification of EPEG tokens, and even allowing regex inside EPEG rules, but I decided against it, as it would mean my EPEG parser would have to parse on the character-by-character level, which would introduce some difficulties in both the implementation and the specification syntax, and would also be less efficient, at least if the parsing is down in a high-level language like I’d planned. Though if I weren’t lazy, I could just create a unique token for each regex specification and include it in the lexer definition…
• There should be a way to specify “semantic actions” in both the parser and the lexer, but, IMO, the actual language used for the functions defined thereby should depend on the parser’s/lexer’s implementation and therefore should not be part of EPEG’s specification. But the syntax for associating the functions with the rules should itself be part of the grammar. Maybe the syntax could be that the code goes inside of {} right after the rule definition like in BISON.

My algorithm for the parser is…

1. Convert the grammar to a graph. For example, if the EPEG code is

   foo = 'x' bar 'y'
   bar = 'a'*
   

   Then the graph will be a node beginning a rule called foo. which points to a node containing x, which points to a node beginning a rule called bar, which points to a node containing a, which points to itself and also to a node containing y, which is understood by some denotation to be outside of the bar rule and to be another part of the foo rule.
2. Start following symbols in the graph one at a time, while reading the input tokens in the text to be parsed, and comparing them to the successive symbols.
3. Wherever the graph splits, such as with the presence of an | (‘or’), follow both lineages simultaneously. For example, in the graph described above, if you were parsing xaay, the symbol in the graph that matches the first a would point to itself, as well as to y, so the next a would be compared to both the a node and the y node. (This example shows the clever way in which * is to be implemented.)
4. Poll the next symbol for each of the paths currently being followed, until one of the symbols matches the next token.  The order in which the current paths are polled and compared to the next token depends on which rule has precedence in the grammar specification.
5. Wherever one of the next symbols polled from the various paths doesn’t match the next token, drop that path from the list of paths currently being compared.
6. If the next symbol in a path starts a rule and it matches the next token, then increment the stack pointer.
7. Of course, if the next symbol is another rule specification, then poll the first symbol specified in that rule, which would be the node that node points to. Or, if that node points to yet another rule, then poll the first node pointed to in that rule, etc.
8. Of course, if the rule has a |, then split the paths and poll all the next symbols, which are the first symbols on either side of the `|
9. If the next symbol in a path ends a rule and it matches the next token, then decrement the stack pointer, and add the name of the rule and the sequence composing it to the current stack level.  The final output will be the sequence at stack[0].
10. Each token encountered and matched is appended to the string of tokens currently pointed to by the current stack pointer.
11. If a token doesn’t match anything in any of the current paths being followed, then of course report that the input is invalid/doesn’t adhere to the specified grammar.

So, in the grammar specification given in the PDF linked to, which was…

S = A '#'
A = 'a' A 'b'
    |  'c' 

it would…

1. Poll ‘c’ and ‘A’ from the grammar in concurrent lineages, where ‘A’ expands to ‘a A b’, so your current symbols you’re polling to compare the next token to are ‘c’ and ‘a’.
2. If the next token is ‘c’, collapse the ‘A’ rule and poll what follows it in the graph, the ‘#’
3. If the next token after ‘c’ is ‘#’, then end, because ‘#’ is an end-state in the graph. (If there are further tokens to be read, report invalid syntax.)
4. If the next token was ‘a’ instead of ‘c’, add one to the stack pointer, drop the ‘c’ lineage, and keep following the ‘a A b’ lineage, which would mean your next polled values are ‘a’ and ‘c’
5. If the next token is ‘c’, go to 2.
6. If the next token is ‘a’, go to 4.

So, if, for example, you had two nested |s in the grammar, that would generate a parsing graph that would make the parser compare each input token to four different graph symbols until one matches, for as long as the input text falls under both nested |s.

In the bar = 'a'* rule above, the a node would point to itself first, then to the y node. But, if the rule were bar = 'a'*?, the a node would point to the y node first, then to itself.
Similarly to how 'a'* would result in a node pointing to a first and then to the next symbol, while the pointers in 'a'*? would be in the reverse order, 'a'+?, 'a'??, and 'a'{2,3}? vs. 'a'+, 'a'? and 'a'{2,3} would also work by reversing the orders of the pointers.
'a'+ would be implemented the same way as a followed by 'a'*.
'a'{2,3} would be implemented in the same way as (aa)|(aaa) would.
'a'? 'b' would be implemented as a node containing ‘a’ that points to both the ‘b’ node and the node after it.
!('a' foo) would be implemented with a special node type starting the pattern that tells the parser it’s a ‘not’, so that if the entire pattern is exhausted while matching the input data, the parsing fails with a syntax error. The first node of the pattern would also point to what comes after the end of the pattern, so that once the matching fails, it can follow that pointer to continue.
&('a' foo) would be implemented with a special node type starting the pattern that tells the parser it’s an ‘and’, so that if the entire pattern is not exhausted while matching the input data, the parsing fails with a syntax error. The first node of the pattern would also point to what comes after the end of the pattern, so that once the matching succeeds, it can follow the pointer to continue.